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This document presents the results of an investigation into the 
feasibility of implementing a dual mode machine that will 
support both Atari PCS and CP/M software. Several architectures 
are proposed, based upon a preliminary analysis, and the pros 
and cons of each architecture are discussed. 


REQUIREMENTS 

My understanding of the requirements of the dual mode machine 
are as follows: 

1. The machine must be capable of running either Atari PCS or 
CP/M software. 

2. The mode switching mechanism must be simple, such as: 
changing a diskette, changing a cartridge, changing a RAM/ROM 
module, toggling a switch, etc. It is not acceptable to 
disassemble the hardware, change an internal PC board and 
reassemble the hardware. 

3. It is cesireable, but not required, that the dual mode 
machine fit in the standard 800 package, without external 
hardware modules. 

4. CP/M is to have access to all of the Atari PCS input/output 
facilities, peripheral devices and game controllers, but not 
necessarily directly. It is not required that CP/M have direct 
access to all of the 6502's memory (ROM/RAM/cartridges). 

5. The standard line of Atari PCS peripheral devices will work 
in either mode, without alteration. 


ASSUMPTIONS 

In analyzing the possibilities, I have made the following 
assumptions: 

1. CP/M diskettes to be used by this machine will have CP/M 
logical formatting (directory, file structure, bit map, sector 
format}/ but will have standard Atari physical formatting 
(track and sector layout, recording technique and sector size). 

2. Software emulation of an 8830 processor (by a 6502) would be 
so slow that CP/M operating under such an emulator would be 

unusable. 

3. Rewriting the PCS Resident Operating System in 8080 code 
would be impractical. 

4. The dual mode architecture will incorporate two co-resident 
CPUs, a 6502 and an 8080 type CPU, as a result of assumptions 2 
and 3. 
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CP/M REQUIREMENTS 

A machine that will support standard CP/M must provide the 
resources shown below. 

1. 8080 type CPU 

2. 20 Kbytes of RAM memory. 

3. Primitive I/O facilities, as shown: 

Disk read and write a single sector 
Console read and write a single character 

Optionally, read and write a single character for auxilliary 
dev ices 


HIGH-LEVEL SYSTEM DESIGN 

A high-level system design that satisfies the stated 
requirements, and can be achieved with minimal changes to the 
existing Atari PCS design, utilizes an independently operating 
8380 type CPU (8080, 8085 or Z80) which can communicate with the 
6502 CPU as shown in the block diagram. 


6502 processor 8380 type processor 
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The "pipe" through which the two processors communicate can be 
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any medium by which communication may be achieved. Examples 
would include shared RAM, a FIFO buffer, the serial bus, the 
controller ports or a set of I/O ports. How the pipe works, and 
how data is transferred between the BIOS and the SERVER is 
addressed in the next section, as there are several viable 
alternatives, all with different advantages and disadvantages. 

With this model, all user I/O is ultimately handled by the Atari 
Resident Operating System (plus non-resident handlers). CP/M 
initiates an I/O operation by calling its own BIOS (Basic I/O 
Subsystem), the BIOS then requests the SERVER to perform the 
operation by signaling the SERVER through the pipe, the SERVER 
performs the indicated operation and signals the BIOS that the 
operation is complete, the BIOS checks the status of the 
operation and then returns to CP/M. 

Note that CP/M was designed to be easily transferred to new 
hardware environments and that all CP/M I/O goes through a 
standard ('well documented) BIOS interface. The CP/M BIOS calls 
are of the level of: get a character from the console, put a 
character to the console, read a sector from the disk, and write 
a sector to the disk. 

USER VIEW OF THE SYSTEM 

The user will initially configure the system at power-up time; 
if a CP/M system disk is in his disk drive when the PCS is 
turned on, then the system will come up operating under the CP/M 
operating system. Conversely, if an Atari DOS disk is in his 
disk drive, or if there is no disk, then the system will come up 
as it does currently. There is a possibility that mode 
switching can be accomplished without turning the power off and 
on, but this is dependent upon details of the implementation 
(such as whether the SERVER is RAM resident or is in a 
cartridge). 


POSSIBLE SYSTEM ARCHITECTURES ] 

Three architectures immediately come to mind as possible 
solutions to the requirements: 

Dual processors, shared bus (shared memory) 

Dual processors, non-shared bus, some shared memory 

Dual processors, non-shared bus and memory, communication port 

Each of these alternatives is given a cursory analysis, 
presenting the most obvious pros and cons. 
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1. Dual processors, s hared bus (shared memory) 

This configuration assumes that both processors share the same 
data bus (not necessarily concurrently, possibly in a ping-pong 
fashion). The CP/M processor would thus have direct access to 
all of the PCS’S RAM and I/O ports. 

pros 

Data can be read directly from disk to the target memory buffer 
with no intermediate buffering required. Data written to disk 
shares this same advantage. 


cons 

Requires design changes to the PCS motherboard due to memory 
contention problems with the ANTIC chip’s DMA. 

Unless memory mapping is incorporated, CP/M's usable RAM space 
is limited to approximately 45 Kbytes, probably less. 


2 . _ Dual processors, non-shared bus, some shared memory 

This configuration assumes that both processors have their own 
unique data bus and can operate concurrently (although there may 
be no great advantage in doing so). The communication pipe is 
implemented as a small (1 Kbytes or less) block of RAM that can 
be accessed by either processor. 

pros 

CP/M’s usable RAM space is a full 64 Kbytes, assuming no mapping 
hardware. 

If it is advantageous to do so, the processors may operate 
concur rently. 

cons 

\ A P 

Requires some form of access control and arbitration for the 
shared RAM; this can be simple since ANTIC need never access 
this block of RAM. 

Disk data needs to be buffered in and out of the communication 
RAM by the CP/M BIOS; this disadvantage is tempered by the fact 
that the Z80 (if used) has a high speed block move instruction. 


3. Dual processors, non-shared bus and memory, communication port 

This configuration assumes that both processors have their own 
unique data bus and can operate concurrently (although there may 
be no great advantage in doing so). The communication pine is 
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implemented as something other than directly accessable RAM; for 
example, the serial bus or the controller ports. 

pros 

CP/M'.s usable RAM space is a full 64 Kbytes, assuming no mapping 
hardware. 

If it is advantageous to do so, the processors may ooerate 
concurrently. 

Needs no form of access control and arbitration as for the 
shared RAM design. 

The CP/M related hardware can be made external to the main unit 
and can be packaged similarly to a standard Atari peripheral 
device. 

cons 


Disk data needs to be buffered in and out of the communication 
port by the CP/M 3IOS, and has to be buffered again by the Atari 
SERVER. The passing of data through the port itself will 
undoubtedly be much slower than accessing RAM. These negative 
features, when combined, will lead to very slow disk I/O. 


PHYSICAL PACKAGING OPTIONS 

Various opt ions are available regarding the physical packaging. 
Some of these options are identified below, with an indication 
of which architectures apply. 
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Note ] -- If the ROM/RAM address/data bus may be brought out of 
the unit using a flat cable, then the option is possible. 

Note 2 -- I am referring to the expansion hardware residing on 
one or more modules which plug into the RAM expansion 
connectors . 

The packaging to be used will be determined after evaluating at 
least the following considerations. 

Ease of installation (retrofit) 

Compatibility with PCS product line (400, 8C0, Nancy) 

Marketing strategy 

Appearance 

Size 

Price 

System performance (I/O throughput) 

Expandability -- RAM expansion and peripheral add-on 
Generality -- applicability to other CPUs and/or software 
systems 

Power requirements 
Heat dissipation 
RF emissions 


MISCELLANEOUS CON SIDE RAT10N3 

The following items are loose ends that must be considered at 
some early date in the development process. 

1. Licensing of CP/M through Digital Research, Inc. 

2. Atari CP/M disk manufacturing -- does Atari want to do this 
or let it be done by third party vendors? 

3. Intended market -- who wants this configuration and T why? 

4. What software is available via CP/M that we don't already 
have (and won't have by the time this product is available) that 
is also useful and of high quality? 

5. A CP/M system disk utilizes how many sectors for the system 
itself? 

6. Speed --on benchmarks, our disk I/O will be slow compared to 
other CP/M systems. 


CONCLUSIONS 

I am excited about this idea in concept, and am encouraged by 
the results of this initial feasibility study. The second 
architecture considered (dual processor, non-shared bus, with 
some shared memory) seems to have a reasonable chance of being 
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implemented, and performing its intended function. 

The primary question in my mind is whether the effort is 
war ranted based solely upon the sale of CP/M systems. Might not 
the effort be better spent on a design which is targeted for a 
Unix system utilizing the 68000, or some general expansion 
mechanism in which CP/M is just one of several options 
available? 
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